云计算的普及和移动互联网应用的繁荣，特别是大数据的兴起，为云-端融合的研究与实践带来了新的挑战和机遇。一方面，云计算的“资源孤岛化”趋势使得云资源难以按需使用，极大限制了云-端融合应用的广度。以亚马逊、Windows Azure、阿里云、腾讯云为代表的公有云，和利用威睿(VMware)、Windows System Center、OpenStack等建立起来的各种私有云，为用户提供了越来越丰富、带有差异化的平台服务，并以此竞争和锁定用户。部署在一个云上的应用很难使用另一个云的软硬件资源，应用在不同云之间迁移的成本也越来越大。换言之，某个公有云或私有云所管理的计算、存储、网络、平台等软硬件资源，对于这个云以外的应用而言，就像“信息孤岛”一样难以互联互通和按需使用。另一方面，“信息孤岛”现象使得大部分互联网应用内部的数据和功能很难作为资源开放共享，严重制约了云-端融合应用的深度。大数据标志着数据成为新一代信息技术的战略资源，理应成为云-端融合中最重要的一类资源。然而，互联网上主流或常见的Web应用（浏览器/服务器架构）、PC应用（客户机/服务器架构）、移动应用（应用/服务器架构），由于大量采用开发框架和中间件，使其内部封装的业务数据和功能因分散、交织、碎片化而无法直接开放共享，系统重构的时间和人力成本大、风险高，由此形成互联网上普遍的信息孤岛现象。

从资源管理的角度看，较为理想的云-端融合应该是指以云计算和智能终端为主体的互联网上的存量和增量资源均可以被任意（授权的）软件使用。从这个角度出发，不难发现，现有方法和技术还有诸多局限和不足。例如，资源管理上种类相对有限，形式相对单一，难以适应云-端融合环境下资源管理机制异构多样的需要；应用对资源的使用模式相对固定和静态，难以应对资源管理需求开放多变的挑战；资源管理大多关注特定类型资源的局部优化，对于云-端融合的复杂应用缺乏全局的视角，导致管理质量复杂难控。

针对云-端融合环境下软件技术面临的挑战，北京大学自2007年起开展研究[1~4]，主要针对计算和数据两类资源的开放融合，提出了一种应用构件模型，用来规约应用对资源使用的能力描述，基于软件定义和运行时模型等技术构建了运行支撑框架，基于代码分析与重构实现了对安卓应用和Web应用的云-端融合化改造。这些研究成果所形成的云-端融合应用运行平台也转化成为燕云基础设施即服务(IaaS)管理系统和数据即服务(DaaS)管理系统，从产业的角度探索并实践了云-端融合的应用场景与前景。

云-端融合应用构件模型

在云-端融合环境中，各类资源被分散在多个云端或终端上。因而，应用对资源的按需使用意味着应用模块在端点上可以灵活可变地部署和运行。为了使终端应用具备灵活调用各类资源的能力，我们提出了面向云-端融合的终端应用构件模型，将终端应用封装为一个构件[1]。该构件模型建立在经典的模型-视图-控制器(Model-View-Controller, MVC)体系结构风格和面向服务的体系结构(Service Oriented Architecture, SOA)风格之上，作为构造云-端融合型应用的编程抽象。与传统构件类似，符合该构件模型的应用包括构件实现和构件接口两个部分。构件实现部分，按照模型-视图-控制器风格分为三个部分。

● 模型　定义了构件所需的数据类，用以封装构件使用的数据结构（包括属性和属性类型），同时还定义了从本地或远程数据源获取数据对象并实例化的方法。在此基础上，开发人员可对模型进行配置，指导运行平台实现数据的云-端按需访问。

● 视图　定义了用户界面中包含的元素及其展示和布局信息，还定义了如何将元素上的用户操作转换为构件控制器中的功能。基于这些用户界面信息，运行平台会根据当前设备的屏幕尺寸和分辨率，自动对视图进行重构和适配。

● 控制器　定义了一组功能函数，实现构件的主要业务逻辑，并描述应用如何操作模型和视图元素。例如，开发人员可在配置文件中声明消耗计算资源较多的计算逻辑，并指导运行平台动态地将这些函数迁移至云中执行。

除了传统的构件封装功能，终端应用构件还封装了用于云-端服务以及人机交互的接口。因此，云-端融合应用构件不仅具备服务接口，还提供视图接口。

● 服务接口主要负责对外暴露构件的功能，使得外部的其他构件甚至云服务表现为一组RESTful风格的应用编程接口。多个构件之间可以通过服务接口相互调用，实现多个构件之间的数据交互和功能组装。服务接口基于构件实现模型定义的数据以及控制定义的功能，由方法与事件两部分组成。其中每个接口中定义的方法对应一个控制函数，用于查询、修改构件（及其数据模型）的状态。事件则定义了构件状态的变化。构件控制函数中可以触发一个事件，供其他构件订阅，以便其他构件获知某个构件状态的改变并执行必要的方法。

● 视图接口指向一个构件实例视图的根元素。也就是说，当一个构件被实例化之后，可以通过视图接口获得该构件视图根元素的引用。通过该引用，其他构件可以操作该构件的视图，或实施进一步的构件视图组装。

在具体实现方式中，终端应用可以是本地应用，也可以是Web应用，由终端运行支撑机制对每个构件进行实例化，将其解释执行为标准的终端应用程序。我们针对本地应用和Web应用，分别在安卓操作系统和网页浏览器中实现了运行支撑机制，包括资源适应框架、构件封装框架和构件组装框架三个部分。资源适应框架根据终端设备、网络运行情况以及用户需求，实现数据的云-端存储、计算的云-端迁移和界面的自动适配；构件封装框架则提供一种通用的机制，将传统Web应用、Web服务和本地应用等封装为符合模型-视图-控制器模型的构件；构件组装框架通过事件总线实现各类构件的消息传递、数据交换和功能调用。

云-端融合资源的软件定义化

在实际情况中，各类软硬件资源基础管理能力和调用异构多样，可能采用脚本文件、配置文件和控制台等多种方式，这种管理能力的异构性给云-端融合中资源的按需使用带来了巨大的挑战。我们采取了“软件定义”的思路，将各类资源的管理能力都以应用编程接口(API)的形式来展现，进而在应用开发中对这些管理能力进行编程调用。

对于云端和终端上各类基础软硬件资源，我们基于其管理能力执行过程中产生的数据流，定义了一种基础管理能力规约模型，将不同类型的管理操作转化为API，使得管理程序可以直接调用。以管理控制台为例，实时捕捉管理控制台的所有用户操作产生的数据流，自动生成可回放的操作序列，并生成相应的API，在API被调用时自动回放操作序列以真实操作控制台完成管理。针对PowerVM和VMware ESXi这两种主流商业虚拟机资源，即便没有开放API或仅对商业伙伴开放部分API，也可以通过我们自动生成的API直接管理甚至在线接管。

相对于基础软硬件资源，应用中蕴含的数据资源开放融合的挑战要更大，在大数据意义下的价值也更大。原因在于，这些应用可能是黑盒构件，缺少或没有源代码和开发文档，且数据开放不能违反其原有系统体系结构的安全性约束。应用开发者通过编写业务逻辑和人机界面来处理数据，也就是说，这些数据访问逻辑均“隐含”在终端应用的程序代码之中，但往往分散在源代码中的不同地方，而且还可能被开发框架所混淆。基于云-端融合构件模型中定义的模型-视图-控制器规约，我们结合Java字节码和JavaScript程序分析技术，综合业务代码层（包括方法调用序列、配置和脚本文件等）、人机界面层（如表单、布局等）、网络协议层（传输控制协议层数据流）和用户交互行为等多方面的信息，进行逆向分析，从人机界面学习并生成业务数据的API。该方法无须依赖原应用开发者、无须开放后台数据库和业务系统、不修改原有系统，自动重构数据接口，而且数据读写规则与原有应用系统完全一致，完全遵循原有应用系统的访问、安全策略，即以非侵入式数据库方式，从业务层面获取数据资源保证数据安全。

云-端融合资源的管理与优化

从管理功能可编程的角度看，计算、存储、网络、电量、应用数据和功能等资源的开放融合，意味着大量的编程工作。为此，我们提供了一种领域特定语言SM@RT，允许开发者、管理员甚至用户基于国际建模标准MOF/QVT高效地编写资源管理程序。我们扩展了模型驱动软件开发中主流的Eclipse EMF代码生成框架，生成了多种常见软硬件资源管理所需的Java代码，代码生成率达1∶40。

我们还提出了一种调用资源API的程序片段自动生成方法，通过分析资源API已有的测试用例代码，发现被管理资源的内部属性可自动构造成每一个属性所对应的代码片段。每个代码片段包含一个源变量、若干辅助变量以及一个API调用链。我们基于自然语言处理技术生成资源API的语义标签，描述资源API涉及到的被管资源的生命周期、依赖关系、工作状态和参数等，自动规划一组资源API的调用序列来处理这些语义标签数据，以完成特定管理任务。这些自动生成的API调用序列与手工构造的序列匹配度可达90%。

针对API大多基于超文本传输协议(HTTP)的现状，我们进行了调用性能优化。在调用不同资源管理API时，通过复用相同的资源API调用请求，可减少60%的网络请求。如果多次调用类似的API资源，通过在超文本传输协议缓存层面复用调用结果中相同的数据，可使响应速度提高20%。

遗产应用的云-端融合化改造

从软件工程角度看，基于上述云-端融合构件模型和运行平台开发应用是一种理想状态。事实上，包容式发展是互联网技术的主线，如何使得百万以上的已有终端应用和云端应用快速、低成本地具备云-端融合能力，是规模化实用的关键。在软件技术体系中，重构是不改变软件应用的外部行为而对其内部结构进行调整的基本方法。因此，我们针对Java和Web两类主要的遗产应用形式，通过自动重构技术，调整其体系结构以按需使用云-端资源。

我们在提出了面向Java字节码的重构方法DPartner，可以将单机Java应用转换成云-端融合型应用[2]。首先，以Java对象为基本单元，通过计算反射原理在具有调用关系的对象之间插入智能代理，该代理生成API以访问并细粒度地操控各个对象需要的CPU计算资源，使得应用具备感知与调用云端（虚拟机）和终端计算资源的能力。然后，通过软件体系结构分析建立基于聚类关系的对象聚合分解层次图，并在字节码层次按照对象之间的依赖关系自动地将原有应用按需重构为终端本地对象和云端远程对象。在运行时，根据当前环境下的计算资源拥有量，从运行时体系结构的对象依赖图中选择能匹配资源供需的某一层中的类簇（模块），并基于这些类簇来进行图最小割集求解算法以计算出最终的资源调度方案。其次，智能代理分别调用本地对象和远程对象并执行相应的管理API，自动同步两端的对象和环境状态。该方法可以通过聚类层次图来快速定位需要调整的部署结构，降低了运行时开销，更能适应动态多变的网络环境。实验结果表明，在典型的计算密集型安卓Java应用（如3D赛车、黑白棋等）上，我们的方法提升了20~100倍性能，节省了20%~90%终端电量。至今为止，DPartner仍是已知的唯一具备如此复杂重构能力的工具。与密歇根大学的同类工作COMET相比，二者在性能提升上效果相当，但DPartner通过运行时软件体系结构是来动态地实现以对象为单位的状态同步和云端-终端自适应资源调度，因此，相对于COMET通过分布式共享内存和镜像传输的方式而言，DPartner网络数据传输量节省了数十倍，适用范围更广。

基于类似重构方法，我们在SPLASH 2012[3]和WWW 2015[4]的工作中，根据JavaScript函数式语言动态特性，构建了云端-终端分布式函数依赖图和迁移机制，对其进行动态重构，将计算密集型任务和可适配型资源处理任务（如图片压缩和缓存），放在云端执行，再将结果和终端本地同步。在不同的终端设备和浏览器上测试后，性能提升5~33倍，电量节省19%~83%。

云-端融合运行平台的产业实践

我们在2009年推出开源版的“北大云操作系统”，管理了北京大学、清华大学、南京大学、中国科学院等单位的数十台服务器并提供“基础设施即服务”；2013年推出商用版的“燕云管理系统”，是目前唯一可以在线接管VMware和PowerVM虚拟机实例的基础设施即服务管理系统，陆续转化为联想和方正等多个IT企业的云管理产品，广泛应用于政务、交通、电信、医疗等多个行业领域。

基于应用系统数据API，我们在“燕云管理系统”中进一步研制了“数据即服务”平台，初步实现了应用数据资源的开放与融合。与斯坦福大学、麻省理工学院、谷歌公司、苹果公司等同类技术相比，燕云管理系统的数据即服务平台是目前唯一在不需要后台权限、不需要系统源码、不破坏既有安全体系下，打破Web、App、PC等三类信息孤岛，自动生成数据读写接口的技术。已在30多个省市和部委的300多个互联网+政务、惠民工程、新型智慧城市项目和系统中应用，覆盖公安、司法、教育、农业、通信、能源、电力、交通等行业。与传统的信息孤岛数据开放共享方案相比，工程效率平均提高百倍以上。

云-端融合的应用前景展望

以应用程序在移动互联网上任意流动为初衷的“软件定义”，使得硬件资源能够以API的形式使用和管理，不仅正在改变网络、存储、计算等IT设备制造行业，也开始推动网络通信和云计算技术体系的演进。

比硬件资源开放、共享、融合更为重要的趋势是软件资源，尤其是数据、功能、规则、流程等应用层次资源的开放、共享、融合。在大数据时代，如果数以亿计的Web应用、移动应用、桌面应用，甚至物联网应用内部的数据和功能都能成为开放共享的资源，那么由此将产生众多价值巨大，甚至改变某个行业的新型应用。例如，“应用内搜索”是指移动App内数据可以像Web数据一样搜索和浏览，是公认的未来移动搜索的主流，其核心技术挑战在于如何通过有效的技术手段（如软件定义）按需、安全地开放App内部的数据和状态。又如，“云管端融合”是指智能终端应用的计算和存储在互联网云中心和5G云基站之间动态迁移，从而在保证互联网云服务商权益的前提下，提高5G资源利用率、降低对固网的依赖、提升终端用户体验。这是4G向5G演进的主要应用场景之一，其核心技术挑战在于如何让数据和代码在终端、云端、管道三者之间按需、可信地分布、迁移和协同。